[Previous] [Next] [Index] [Thread]

re: what are realistic threats?



There's a couple ways to attack the threat question. The classic
security-centric way is to look at just the technology,
uncontextualized, then to lop off the difficult parts of the problem
you just don't feel you can solve (government agencies or similarly
funded and experienced organizations, denial of service, and traffic
analysis often fall into this category).

Then there's "assuming how it's used today, by the people who are
using it today, in the ways they're using it today". I think that's
where Dave and Phill are mostly coming from. However, if you just talk
the technology that will solve the threats (public keys for signing
and encrypting, for instance) you shouldn't forget deployment (how
people get all the public keys for all the people they'll communicate
with, for instance). That means services that are trusted (at least to
the extent that they're available, to prevent total denial of
service), as well as scalable. Then there are WWW architectural
gotchas (proxies and caching). 

The classic security services for contering threats are
authentication, authorization, data integrity, and data protection
(privacy). Authentication is pretty useless without authorization, but
sometimes the authorization models are so simple as to not matter (if
I can authenticate them, they can do anything, as in node login). As
Phill points out, this is unlikely to be good enough for people using
HTTP methods that alter data. We plan on using DCE authorization
services to create a simple ACL manager that maps HTTP methods to ACL
permissions, as a start. Services like Kerberos, S-HTTP, and Shen seem
to address all of these. But they're all communications-centric. In
terms of document integrity, people will begin to want signed
documents, not signed communication of documents (who's the author,
not just who's the server). And there's been some discussion on
www-talk of how to control information dissemination from the point of
view of publishing (an authorization problem that's classically been
solved with Mandatory Access Controls, which would never work on the
Internet). 

Then there's "how do people what to use it" or, more likely "how do we
think people will want to use it when we've done things to it". It
seems to me that how businesses use the network is different from the
classic Internet model. Businesses will want the same sorts of
services mentioned already, but in ways that are easy to administer,
and fall in line with their organization model (usually hierarchies of
groups, perhaps loosely connected trees). And, I think we should ask
people who they want to use it (I plan on doing that soon). That's
something that really can't be done well on www-security, since
there's very few "users", and vastly more "providers". 

So, Dave, can you be more specific? :-)
	Mez


Follow-Ups: